Internet Surfer 2.0/Internet Surfer 2.0 (Wayzata Technology) (1996).iso/pc/text/mac/faqs.556

Text File | 1996-02-12 | 14.7 KB | 352 lines

Frequently Asked Questions (FAQS);faqs.556



  Oliver Jones ([e-mail]):
    Keep fonts local to the workstation, rather than loading them over nfs.
    If you will make extensive use of R5 scalable fonts, use a font server.

About the Resources File
- - - - - - - - - - - - -

  Joe English ([e-mail]) :
    Keep your .Xresources and .Xdefaults file small.  Same effect as
    [reducing the number of fonts].

  In your .Xdefaults (.Xresources) file, try just putting the minimum
  amount of resources that you want to have available to all your
  applications.  For example:  *reverseVideo: true

  Then, separate your resources into individual client-specific
  resource files.  For Example: I store mine in $HOME/lib/app-defaults.
  In my .login file I set the environment variable XUSERFILESEARCHPATH:
      setenv XUSERFILESEARCHPATH $HOME/lib/app-defaults/%N

  So, when I launch an xterm, it loads its resources from
  ...app-defaults/XTerm.  Xdvi finds them in .../app-defaults/XDvi,
  and so on and so forth.  Not all clients follow the same class-naming
  convention, so you may have some fun figuring out what to call the
  resource file (xterm? Xterm? XTerm?).  In general, try following the
  standard XXxxx pattern first.

  This method of organizing your personal resources has the following
  benefits:

  - Easier to maintain/ more usable.

  - Fewer resources are stored in the X server in the RESOURCE_MANAGER
    property.  As a side benefit your server may start fractionally
    quicker, since it doesn`t have to load all your resources.

  - Applications only process their own resources, never have to sort
    through all of your resources to find the ones that affect them.

  - the application that you are interested in has to load an additional
    file every time it starts up.  This doesn't seem to make that much of a
    performance difference, and you might consider this a huge boon to
    usability.  If you are modifying an application's resource database,
    you just need to re-run the application without having to "xrdb" again.

  This is all documented in the Xt Specification (pg 125 & 666).
            [Thanks to: Kevin Samborn ([e-mail])
             and Michael Urban ([e-mail]) ]

  The "comp.windows.x Frequently Asked Questions" FAQ list contains an
  excellent explanation of how these environment variables work.

  NOTE: xrdb will by default run your .Xdefaults file through cpp.
    When your resources are split out into multiple resource files
    (as described above) and then loaded by the individual client
    programs, they will NOT be processed first through cpp.
    WATCH OUT FOR THIS!!

    I had C style comments in my .Xdefaults file, which cpp
    stripped out.  When I switched to this method of distributed
    resource files I spent several frustrating days trying to
    figure out why my clients were not finding their resources.  Xt
    did *NOT* provide any error message when it encountered those C
    style comments in the resource files, it simply silently
    aborted processing that resource file.

    The loss of preprocessing (which can be very handy, e.g. ``#ifdef
    COLOR'' ...) is enough to cause some people to not be interested in
    this method of resource management.

  You may also run into some clients which break the rules.  For example,
  neither Emacs (18.58.3) nor Xvt (1.0) will find their resources if they
  are anywhere other than in .Xdefaults.

  On other ``gotcha'' to watch out for is starting up a client on a
  machine that does not share files with the machine where your
  resources are stored.   In this case your client will not find its
  resources.  Loading all your resources into the server will guarantee
  that all of your clients will always find their resources.
                                Casey Leedom ([e-mail])

Define Your Display Properly
- - - - - - - - - - - - - - -

  Client programs are often executed on the same machine as the server.  In
  that situation, rather than setting your DISPLAY environment variable to
  "<hostname>:0.0", where <hostname> is the name of your workstation, you
  should set your DISPLAY variable to "unix:0.0" or ":0.0".  By doing this
  you access optimized routines that know that the server is on the same
  machine and use a shared memory method of transferring requests.
            [thanks to Patrick J Horgan ([e-mail])]

  See the _DISPLAY NAMES_ section of the X(1) man page for further
  explanation of how to properly set your display name.

-------
Clients
-------

  If you only have a few megabytes of Ram then you should think
  carefully about the number of programs you are running.  Think also
  about the _kind_ of programs you are running.  For example:  Is there
  a smaller clock program than xclock?

  Unfortunately, I haven't really noticed that programs advertise how large
  they are, so the onus is on us to do the research and spread the word.

  [ Suggestions on better alternatives to the some of the standard clients
  (eg: Xclock, Xterm, Xbiff) are welcome.  --ed.]

  One thing to note on systems with shared libraries, is that once Xaw,
  Xt, Xlib, etc are loaded, they don't have to be loaded again.  So if
  you already have an Athena program loaded, xclock won't add much to
  the load.  This is an argument against non-Athena programs, that load
  extra code.  The moral of this story is to keep to one set of
  libraries -- don't mix your toolkits (e.g. XView and Xt).
      Duncan Sinclair ([e-mail] | [e-mail])

A Better Clock for X
- - - - - - - - - - -

  Richard Hesketh ([e-mail]) :
    xbiff and xclock are written using the X toolkit and are therefore
    rather large ...

  Duncan Sinclair ([e-mail]) told me about ``xcuckoo'', which
  displays a clock in the title bar of *another* program.  Saves screen real
  estate.  I haven't tried this one out yet.  Find it on export...

  der Mouse ([e-mail]) :
    For your consideration I offer mclock, my clock program.  It is
    non-Xt-based, which alone should help, and is extensively
    configurable:  it can be made to look very much like MIT oclock, or
    mostly like xclock purely by changing resources.

    You can get this by anonymous ftp from larry.mcrcim.mcgill.edu
    (132.206.1.1), /X/mclock.shar

  I've tried this clock program out, and it works fine, but I haven't tried
  any extensive testing to see how it compares to xclock in resource
  consumption.  One point: don't let the size of the executable fool you.
  The binary on my site is about 2.5 times the size of Xclock, but the
  author pointed out to me that mclock does *not* drag in Xaw, Xmu, or Xt,
  which Xclock does.  Therefore, it should be lighter when running.

  Of course, the ultimate clock --- one that consumes no resources, and
  takes up no screen real estate --- is the one that hangs on your wall.
  :-)

A Better Terminal Emulator for X
- - - - - - - - - - - - - - - - -

  From the README file distributed with xterm:

  +-----
  |         Abandon All Hope, Ye Who Enter Here
  |
  | This is undoubtedly the most ugly program in the distribution.
  | ...
  +-----

  Ugly maybe, but at my site it's still the most used.  I suspect that
  xterm is one of the most used clients at many, if not most sites.
  Laziness?  Isn't there a better terminal emulator available?  See below.

  If you must use xterm, you can try reducing the number of saveLines
  to reduce memory usage.  [ Oliver Jones ([e-mail]),
                   Jonny Farringdon ([e-mail]) ]

1) Xvt

  Richard Hesketh ([e-mail]) :
    ... if you don't need all the esoteric features of xterm, then get
    hold of xvt from export.lcs.mit.edu:/contrib/xvt-1.0.tar.Z, it was
    written here just to save swap space as xterm is rather a hog!

  I've since obtained and am evaluating 'xvt' and it does seem to me
  to be noticeably faster than xterm, while yet coming off as a full
  featured "clone" of xterm -- you don't even have to rename your xterm
  resources as xvt pretends to be XTerm.  It is missing a few xterm
  features to which I've grown accustomed, but I'm giving it a try.

2) mterm

  der Mouse ([e-mail]) :
    I also have my own terminal emulator.  Its major lack is
    scrollback, but some people like it anyway.  It can be had from [
    larry.mcrcim.mcgill.edu (132.206.1.1) ], in
    /X/mterm.src/mterm.ball-o-wax.

-------------------------
Miscellaneous Suggestions
-------------------------

Pretty Pictures
- - - - - - - -

  One of the things I did when first learning to use X, was experiment with
  using different images as the background on my display.  (via xsetroot, or
  xphoon, etc).  I soon abandoned this practise for some very good reasons:

  - The more complicated your root window bitmap, the slower the server
    is at redrawing your screen when you reposition windows (or redraw, etc)

  - These take up RAM, and CPU power.  I work on a Sun SPARC ELC with 8mb
    RAM and I'm looking for more power, I can't comprehend it when I see
    people with a 4mb Sun 3/60 running xphoon as their root window.

  If you're anything like me, you need all the screen real estate
  that you can get for clients, and so rarely see the root window anyway.
              [ Thanks to Qiang Alex Zhao ([e-mail])
            for reminding me of this one. --ed.]
A Quicker Mouse
- - - - - - - -

  Using xset, you can adjust how fast your pointer moves on the screen
  when you move your mouse.  I like to be able to send my pointer
  across the screen with just a flick of the wrist, and so I use
  "xset m 5 10" in my .xinitrc file.  See the xset man page for further
  ideas and information.

  Hint: sometimes you may want to *slow down* your mouse tracking for
  fine work.  To cover my options, I have placed a number of different
  mouse setting commands into menus in my window manager.
  e.g. (for twm) :
      menu "mouse settings"
      {
        "Mouse Settings:"            f.title
    "  Very Fast"                ! "xset m 7 10 &"
    "  Normal (Fast)"            ! "xset m 5 10 &"
    "  System Default (Un-Accelerated)"    ! "xset m default &"
    "  Glacial"                ! "xset m 0 10 &"
      }

Programming Thoughts
- - - - - - - - - - -

  Joe English ([e-mail]) :
    To speed up applications that you're developing, there are tons of
    things you can do.  Some that stick out:

    * For Motif programs, don't set XmFontList resources for individual
      buttons, labels, lists, et. al.; use the defaultFontList or
      labelFontList or whatever resource of the highest-level manager
      widget.  Again, stick to as few fonts as possible.

    * Better yet, don't use Motif at all.  It's an absolute pig.

    * Don't create and destroy widgets on the fly.  Try to reuse them.
      (This will avoid many problems with buggy toolkits, too.)

    * Use a line width of 0 in GCs.  On some servers this makes a HUGE
      difference.

    * Compress and collapse multiple Expose events.  This can make the
      difference between a fast application and a completely unusable
      one.

  Francois Staes ([e-mail]) :
    Just a small remark: I once heard that using a better malloc
    function would greatly increase performance of Xt based
    applications since they use malloc heavily. They suggested trying
    out the GNUY malloc, but I didn't find the time yet. I did some
    tests on small programs just doing malloc and free, and the
    differences were indeed very noticeable ( somewhat 5 times faster)

  [ Any confirmation on this from anyone?  --ed.]

Say What!?
- - - - - -

  Some contributors proposed ideas that seem right off the wall at first:

  David B. Lewis (by day: [e-mail], by night: [e-mail]) :
    How about this: swap displays with someone else. Run all your programs
    on the other machine and display locally; the other user runs off your
    machine onto the other display. Goal: reduce context switches in the
    same operation between client and server.

  I'm not in a situation where I can easily try this, but I have received
  the following confirmation...

  Michael Salmon ([e-mail]):
    I regularly run programs on other machines and I notice a big
    difference. I try to run on a machine where I will reduce net usage
    and usually with nice to reduce the impact of my intrusion. This
    helps a lot on my poor little SS1+ with only 16 MB, it was
    essential when I only had 8 MB.

  Casey Leedom ([e-mail]) :
    [The X11 Server and the client are] competing for the same CPU as
    your server when you run it on the same machine.  Not really a
    major problem, except that the X11 client and the server are in
    absolute syncronicity and are context thrashing.

  Timothy H Panton ([e-mail]) :
    Firstly it relies on the fact that most CPU's are mostly idle, X's
    cpu usage is bursty.  so the chances of you and your team-mate
    doing something cpu-intensive at the same time is small. If they
    are not then you get twice the cpu+memory available for your
    action.

    The second factor is that context switches are expensive, using 2
    cpu's halves them, you pay a price due to the overhead of going
    over the network, but this is offset in most cases by the improved
    buffering of a network (typically 20k vs 4k for a pipe), allowing
    even fewer context switches.

----------------------------
Other Sources of Information
----------------------------

  Adrian Nye ([e-mail]):
    A lot more tips on performance are in the paper "Improving X
    Application Performance" by Chris D. Peterson and Sharon Chang, in
    Issue 3 of The X Resource.

    An earlier version of this paper appeared in the Xhibition 1992
    conference proceedings.

    This paper is absolutely essential reading for X programmers.

  [Seems I've got some competition. :-)  --ed.]

--------------
Author & Notes
--------------
  This list is currently maintained by Art Mulder ([e-mail])

  Suggestions, corrections, or submission for inclusion in this list
  are gladly accepted.  Layout suggestions and comments (spelling
  mistak's too! :-) are also welcome.

  Currently I have listed all contributors of the various comments and
  suggestions.  If you do not want to be credited, please tell me.

  speedup-x-faq is copyright (c) 1992 by Arthur E. Mulder

  You may copy this document in whole or in part as long as you don't
  try to make money off it, or pretend that you wrote it.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
--
 ...art mulder ( [e-mail] )    | "Do not be conformed to this world,
 Department of Computing Science         |  but be transformed by the renewal
 University of Alberta, Edmonton, Canada |  of your mind, ..."  Romans 12:2
 University of Alberta, Edmonton, Canada |  of your mind, ..."  Romans 12:2